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Introduction 

When problems occur on spacecraft, onboard and ground-based teams begin to analyze 
the data. Timely access to relevant domain knowledge can mean the difference between a 
nominal, degraded or failed mission. For a spacecraft as large as the ISS, the 
documentation is well over 1 million pages excluding reference materials in the form of 
spreadsheets, diagrams, databases, source code, test results and other domain-specific 
forms of knowledge. This is due largely because ISS is being developed in stages, over 
many years, with many international collaborators. We believe that tools that can provide 
relevant and timely access to these documents and reference materials will decrease 
anomaly resolution time with concurrent increases in safety 



diagnostic state which is mapped to documents, e.g. map Caution and Warning event [10] 
to ISS Reauirements documentation. 

We are developing automated methods to provide realtime access to spacecraft domain 
knowledge relevant a spacecraft’s current operational state. The method is based upon 
analyzing state-transition signatures in the telemetry stream. A key insight is that 
documentation relevant to a specific failure mode or operational state is related to the 
structure and function of spacecraft systems. This means that diagnostic dependency and 
state models can provide a roadmap for effective documentation navigation and 
presentation. 

Diagnostic models consume the telemetry and derive a high-level state description of the 
spacecraft. Each potential spacecraft state description is matched against the predictions 



of models that were developed from information found in the pages and sections in the 
relevant ISS documentation and reference materials. By annotating each model fragment 
with the domain knowledge sources from which it was derived we can develop a system 
that automatically selects those documents representing the domain knowledge 
encapsulated by the models that compute the current spacecraft state. In this manner, 
when the spacecraft state changes, the relevant documentation context and presentation 
will also change. 

Architecture 

The Realtime Knowledge Management (RKM) tool is being developed as an integration 
of three existing software tools: 1) the Diagnostic Data Server [1], a telemetry server that 
which provides a temporally organized set of telemetry, logs and data-dumps of the ISS 
over a selected window of time 2) the Netmark [2] document database that indexes 
documents both on context (document token) and content (ISS token); and 3) the 
ISStrider [3] model-based diagnostic tool [3] developed using L2 [6] which models both 
the hardware and software aspects of the ISS Command and Data Handling (C&DH) 
system. These three technologies are part of a set of engineering support tools that will be 
deployed at NASA JSC in the next two years. 

The flow of information for the RKM architecture follows the numbers in Figure 1: 1) 
Telemetry queries are defined by the diagnostic tool ISStrider (or by the human operator) 
2) telemetry is consumed by ISStrider, which produces 3) diagnoses (in the future 
recoveries as well) and 4) document queries. The document queries to Netmark produce 
5) relevant documents. The telemetry, diagnoses and relevant documents are all 
integrated in user-defined GUIs for rapid access by ISS flight engineers. 
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Figure 2: Realtime Knowledge Management (RKM) architecture which 
integrates DDS f 11, Netmark \ 2 ] and ISStriderf 3 1 . 


Example 

We demonstrate the RKM architecture in Figure 1. using an example from the ISS 
C&DH domain. The DDS serves a realtime Caution and Warning event to ISStrider 
which maps this event to a portion of the ISS software requirements specification (SRS) 





[4]. This example defines a direct mapping between telemetry and corresponding 
documentation (see Implementation Section for details). 

In general the mapping from a Caution and Warning event to domain documentation is 
non-trivial and could require methods that reason about hidden state. For example, the 
documents relevant to interpret a bus Caution and Warning event fe.g CW #5392). 
include a hardware schematic, Bus Address Assignments Table, and the bus profile. Or 
for example the documents relevant to interpret a computer (MDM) failure Caution and 
Warning event (e.g. CW #5104) will require all documents related to both the failed 
execution of the hardware and the software. This would include documents for the 
hardware and software schematics, for requirements specifications, for documents which 
define the Built-in Tests (BIT) and Power-On Self-Tests (POST) tests, for documents 
which define the rate monotonic scheduler and its tasks, and of course for the source code 
itself [8,9,10,11,12,13,14,15,16,17]. 

We are developing additional model-based methods based on internal state variables to 
allow for indexing documents based upon the internal structure and topology of the 
subsystem domain. Below we define the grammar required to implement the RKM 
system. It will also apply to state-less dependency models such as TEAMS as well. For 
TEAMS additional elements will be added to define tests and the source knowledge 
required to model each test. 

Implementation 

The implementation is partitioned into three areas, 1) the grammar to describe the ISS 
document dependencies and the interface into the Netmark document store/database 2) 
the grammar to describe the ISStrider model-based diagnosis models and its links to the 
document dependencies. Once the document dependencies are defined, we can annotate 
our models with the source documents. Our models are based upon the ISStrider system, 
which utilizes the L2[6] model-based diagnosis system. Our approach is also applicable 
for many other diagnostic systems including the stateless structural dependency 
TEAMS[7] tool. For TEAMS focus would be on defining the tests, while for L2 focus is 
on defining the states of the models and its transitions. This is accomplished in L2 
through the use of a model development interface which allows the user to annotate each 
model fragment with documentation. 

Document dependency grammar. To develop a system that can capture ISS specific 
document types, we define a document dependency grammar. The grammar serves to 
map the ISS document types to the Netmark tags for both context and content. Context is 
defined as the sections of documents that are important to index into. We have identified 
a preliminary set of ISS document contexts : 1) document name 2) section 3) page-slide 
4) figure 5) table 6) weblink 7) workbook 8) database 9) source DDS dataset. Content is 
defined with respect to ISS domain features. We have identified a preliminary set of ISS 
document contents : 1) requirement number 2) PUI 3) CSCI (software program identifier) 
4) part number 5) procedure number. 


<doc_dependencv>: := <context>+<content> 



<context>::=<document_name>|<section> | <page-slide> | <figure> |<table>| 

<web- link>|<workbook> |<database-table> | <DDS dataset>J... 
<content>::= Requirement number> + |<PUI> + <CSCI> T |<Part Number^ | 

<procedure number> |<CSCI>+ 

Model-based diagnosis grammar. An ISStrider Livingstone model is made up of a set 
of components which are connected via a set of connections. At each level, including the 
model level, we can annotate the model fragment with documentation dependencies 
which map model constructs to source documents. 

<model>::=<component>+ (<connection>)* <doc_dependency>* 

Each component is defined at its boundaries by a finite set of ports, each of domain 
specific types. Internal to each component, is a finite-state machine which itself is made 
up of a finite set of states. Directed and undirected transitions between the states are 
defined. Executing the transitions in the forward direction is used to perform state 
estimation, while executing the state transitions in the reverse direction is used to perform 
regulation (recovery). 

<component>::=<port>+ <fmite_ state_machine> <doc_dependency>* 
<finite_state_machme>::=<state>+ <transition>* <doc_dependency>* 
<transition>::=<guard> <cost> <state> <state> <transition_type><doc_dependency>* 
<state>::=<logical expression> <doc_dependency>* 

Each connection between components is defined with a type, portname and connection 
specific documentation dependencies. Each port is defined by a type that identifies the 
port as an observation, command or internal port as well the possible values that the port 
can take. Each value is an element of the set of all possible values: {..Vi,Vj..}. 

<connection> ::=<type> <port> <doc_dependency>*. 

<port>::=<port-type> <value-type> <doc_dependency> 

<port-type>::=[observation | command | internal] <doc_dependency>* 
<value-type>::=[(discrete|continuous) <value>+ ] <doc_dependency>* 

<value> ::= {..v^Vj..} <dependency>* 

Discussion 

At any point in time, a ranked set of diagnoses from the ISStrider system exists. Each of 
these diagnoses provide a state vector over the state of each component in the system. By 
identifying the active model fragments, the RKM system, given the current diagnosis 
state, can automatically present the user with the documentation entailed by the diagnosis. 
Since the documentation is being driven by the telemetry, often it will occur that many 
sets of documents are available. This is due to the fact that each diagnosis is composed of 
a set of components and connections. For each components and connections different 
doc_dependencies exist which could point to multiple document sources. We would like 
to compute an intersection of the raw documents in order to provide a unified view to the 
user. For example, if two model fragments point to two requirements (x.x.x.x and 


y.y.y.y). We can first perform a context search on requirement(x.x.x.x) in Netmark. 
which can return a set of pages over a range [lb] ..ubi] in a ISS requirements doc, (e.g 
[4,11]). We can then further constrain this page range through a content search on 
requirement(y.y.y.y) over the range of pages [lb]. .ubi]. This will return a more refined set 
of pages [lb 2 .. ub?] such that lbi <= Ib 2 & ub 2 <=: ubj. 
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